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Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Telecommunications and Internet 
converged Services and Protocols for Advanced Networking (TISPAN). 



Introduction 



The present document describes some identifiers used within 3GPP which are considered applicable to TISPAN with 
the aim to identify a common set of global standard identifiers, at least few of them, that will allow NGN operators to 
satisfy both TISPAN NGN requirements [19] and quality control, security, authentication, emergency, law interception 
and privacy requirements, clause 6 of ITU-T Recommendation Y.2001 (see bibliography). 
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Scope 



The present document provides an overview of the identifiers used within 3GPP which are considered applicable to 
NGN. It is intended that the information contained in the present document are not referred to any specific TISPAN 
Releases, and it shall be used as the basis for defining additional identifiers and related parameters to facilitate the 
implementation of TISPAN NGN standards. 
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3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TR 180 000 (see bibliography) and the 
following apply: 

address: identifier for a specific termination point and used for routeing to this termination point 

E.164 number: string of decimal digits that satisfies the three characteristics of structure, number length and 
uniqueness specified of ITU-T Recommendation E.164 [10] 

NOTE: The number contains the information necessary to route the call to the subscriber or to a point where a 
service is provided. The hierarchical structures of International E.164-numbers [10] are as follows: 
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identifier: a series of digits, characters and symbols used to identify uniquely subscriber(s), user(s), network 
element(s), function(s) or network entity(ies) providing services/applications 

NOTE 1 : Identifiers can be used for registration or authorization. They can be either public to all networks or 
private to a specific network (private IDs are normally not disclosed to third parties). 

NOTE 2: In 3GPP the term Identity' or 'ID' is typically used instead. 

identity: identifier allocated to a particular entity, e.g. a particular end-user, provides an Identity for that entity 

NOTE: The definition currently provided in TR 180 000 (see bibliography): The attributes by which an entity or 
person is described, recognized or known. 

name: identifier of an entity (e.g. subscriber, network element) that may be resolved/translated into an address 

short code: string of digits in the national telephony numbering plan as defined by the national Numbering Plan 
Administration (NPA) which can be used as a complete dialling sequence on public networks to access a specific type 
of service/network 

NOTE: The short code is a non-E. 164 number and its length does not exceed five digits, in exceptional cases six 
digits. An example is the emergency number 1 12 used in the EU. 

tel URI: representation of an international E.164 number or another number with the context defined (e.g. private 
number, short code) 

NOTE: RFC 3966 [3], which defines the use of the tel URI, also uses the term "local number" , but uses it in a 
totally different way from E.164. 
RFC 3966 [3] recognizes: 

■ "Global number" - which always start with +CC. 

■ "Local number" - which is anything that is not a "global number". 

Thus what E.164 refers to as national numbers, "local numbers" and short codes (as well as other types 
such as private numbers) would all be treated by RFC 3966 [3] as "local numbers". In the case of "local 
numbers", RFC 3966 [3] uses a context qualifier to distinguish the type of number. 

In the context of the present document, the term "local number" will be used in the E.164 sense and 
international/national format issues has to be defined in the SIP context. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

3GPP 3"* Generation Partnership Project 

AES A ATM End S y stem Addres s 

AS Application Service 

ATM Asynchronous Transfer Mode 

BGCF Breakout Gateway Control Function 

CC Country Code 

ccTLD country code Top Level Domain (e.g. .fr) 

CLE Connectivity session Location and repository Function 

CLI Calling Line Identity 

CN Core Network 

CPE Customer Premises Equipment 

CS Circuit Switched 

CS/GPRS Circuit Switched/General Packet Radio Service 

CSCF Call Session Control Function 

DHCP Dynamic Host Configuration Protocol 

DNS Domain Name System 

DSL Digital Subscriber Line 

EDGE Enhanced Data GSM Environment 

ENUM E. 1 64 Number Mapping 

FES For Further Study 
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GERAN GSM/EDGE Radio Access Network 

GPRS General Packet Radio Service 

GRX GPRS Roaming eXchange 

GSM Global System for Mobile Communication 

GSMA GSM Association 

gTLD generic Top Level Domain (e.g. .org) 

HPLMN Home PLMN 

HSS Home Subscriber Server 

ICANN Internet Corporation for Assigned Names and Numbers 

I-CSCF Interworking CSCF 

ID Identifier/Identity 

UN Issuer Identifier Number 

IM CN IP Multimedia Core Network 

IM IP Multimedia 

IMPU IMS Public User Identity 

IMS IP Multimedia Subsystem 

IMSI International Mobile Subscriber Identity 

IP Internet Protocol 

ISDN Integrated Services Digital Network 

ISIM IM Services Identity Module 

I- WAN IP- Wide Area Network 

LIE Location Information Forum 

LIR Local Internet Registry 

MCC Mobile Country Code 

MGCF Media Gateway Control Function 

MNC Mobile Network Code 

MSIN Mobile Station Identification Number 

MSISDN Mobile Station ISDN Number 

NACF Network Access Configuration Function 

NAI Network Access Identifier 

NASS Network Attachment Subsystem 

NDC National Destination Code 

NGN Next Generation Network 

NIR National Internet Registry 

NPA Numbering Plan Administration 

NRA National Regulatory Authority 

PBX Private Branch Exchange 

P-CSCF Proxy CSCF 

PDBF Profile Data Base Function 

PDN Public Data Network 

PLMN Pubhc Land Mobile Network 

PPP Point-to-Point Protocol 

PSI Public Service Identifier 

PSTN Public Switched Telephone Network 

QoS Quality of Service 

RACS Resource and Admission Control Subsystem 

RAN Radio Access Network 

RFC Request For Comments 

RIR Regional Internet Registry 

S-CSCF Serving CSCF 

SGSN Serving GPRS Support Node 

SIM Subscriber Identity Module 

SIP Session Initiation Protocol 

SLF Subscription Locator Function 

SN Subscriber Number 

SS7 SignalHng System No. 7 

TETRA Terrestrial European Trunked Radio 

TLD Top Level Domain 

TMSI Temporary Mobile Subscriber Identity 

UE User Equipment 

UICC Universal Integrated Circuit Card 

UML Unified Modelling Language 
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UMTS Universal Mobile Telecommunication System 

UPSF User Profile Server Function 

URI Universal Resource Identifier 

USIM UMTS Subscriber Identity Module 

UTRAN UMTS Radio Access Network 

VPLMN Visited PLMN 

WLAN Wireless Local Area Network 

WTSA World Telecommunication Standardization Assembly 



Background on identifiers for NGN 



NGN must be able to support the existing Naming, Numbering and Addressing plans for fixed and mobile networks. It 
is therefore important to have a full understanding of how these plans work. 

For networks like PSTN/ISDN, GSM-based PLMNs and the Internet there is a common terminology used concerning 
the present identifiers (IDs) used in these networks. The terms, which are defined in ITU-T Recommendation 
E.191 (see bibliography), are name, number and address. In the PSTN the ID is the E.164 number [10] and that number 
is used for identifying and routeing the call to the subscriber/user or services. With the introduction of services based on 
non-geographic numbers and number portability the function of the number has been split between a name role for 
identifying the user or service and an address role to indicate how to route the call to the subscriber's network 
termination point. 

In GSM-based PLMNs the E.164 number is often called an MSISDN to indicate that the E.164 number is used for 
mobile services. Another ID used in GSM networks is the IMSI, based on ITU-T Recommendation E.212 [9]. The IMSI 
provides a unique identifier of the mobile subscription for registration purposes. It is also used to identify the home 
PLMN (HPLMN) when the mobile subscriber/terminal is roaming in a visited mobile network (VPLMN). Most of the 
present SIM cards used in GSM networks are marked with another ID called the Issuer Identifier Number (IIN) 
according to ITU-T Recommendation E.I 18 (see bibliography). An introduction to different IDs used in PLMNs based 
on 3G systems can be found in clause 5. 

4.1 Circuit switch network identifiers 

For circuit switched networks there are also some IDs used for different network functions. For example Signalling 
Point Codes for the ITU-T Signalling System No. 7 (SS7). Some of the signalling point codes are used in the 
international signalling network, ISPCs according to ITU-T Recommendation Q.708 (see bibliography), and some are 
used as NSPCs between national networks. These addresses can be seen as public IDs but there are also signalling point 
codes, with Network Indicator 2, used solely as a private ID inside one operator's network and therefore never disclosed 
to other operators. 

4.2 Packet switch network identifiers 

For packet switched networks like the Internet and other IP based networks names in the form of Domain Names 
according to RFC 1035 [2] are well known and used. For the Internet the separation between a name and an address 
have been used from the early days of the Internet (from the beginning although only IP addresses was the major ID). 

The Domain Name is used to identify the user/host and the IP address used for routeing to the interface to which the 
host is connected (for IP address format IPv4 and IPv6, see clause 7.1.2). The IP address is received through a name 
resolution with the help of the Domain Name System (DNS). Before the growth and success of the Internet other public 
data networks (PDN) based on X.25 (see bibliography) and X.21 (see bibliography) was used and some are still in 
function. For these PDNs a numbering plan based on ITU-T Recommendation X.121 (see bibliography) is used. 

For ATM networks there exist specific address resources named ATM End System Addresses (AESA). Different 
AESAs are used and one (ITU-IND AESA) is administered by the ITU TSB and is based on ITU-T Recommendation 
E.191 (see bibliography). 

There are also IDs from other naming, numbering, addressing or identification plans, like the numbering plan (ITU-T 
Recommendation F.69, see bibliography) for the diminishing telex service, IDs for TETRA networks and more network 
specific IDs like NSAPs (Network Service Access Point), but this clause has no intention to cover all kind of IDs in 
present public networks. 
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As mentioned in this clause, identifiers are used throughout the network to identify sources/destinations of traffic and 
also resources within the network and the E. 164 number is for example used by PSTN users to identify the destination 
of a call. In the context of an NGN, E. 164 numbers need to be translated into other kind of IDs (e.g. IP addresses) 
usable within the NGN. This will be further elaborated in the present document. 



3GPP concept on the use of IDs 



In UMTS based PLMNs there are many specific IDs used and they are described in detail in TS 123 003 [6] . The 
following clauses will highlight some of these 3GPP IDs that also will be applicable in some form in the NGN. 

5.1 An Introduction to UICC, USIM, ISIM, Public IDs, Private 
IDs, Home Domain IDs 

This clause provides an understanding to the Universal Integrated Circuit Card (UICC), the UMTS Subscribers Identity 
Module (USIM), and the IM Services Identity Module (ISIM) and the relationship between all three entities. 

With the introduction of the IMS Domain within 3GPP a single level of registration was found to be insufficient. To 
provide the necessary attributes for registration to IMS to be carried out, an ISIM application was added to the UICC. In 
summary the USIM application is used to gain access to the UMTS access network (CS/GPRS network) and the ISIM is 
used to gain access to the IMS Domain (3GPP Release 6 or greater). 

A subscriber may access the IMS Domain: 

• with the values of the ISIM identifiers derived from the USIM (in the absence of ISIM); 

• with the value of the ISIM identifiers provisioned independently from the USIM. 

It should be made clear from this clause that to access the IMS Domain an ISIM is required (note that the required 
private identifier provided and validated by the operator can be derived from the USIM if the ISIM is absent). As stated 
above, it is possible the ISIM resides or not on a UICC. 




HaiQe DdiiioIii ID 



L\ifi level 



Figure 2: Key 3GPP IDs 

The introduction of the SIM card introduced not only a method of uniquely identifying a subscription irrespective of the 
GSM device being used, but also a higher level of security that was absent from the previous analogue system where 
cloning the handset was common. Cloning a SIM card is much more complex. 
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As with the SIM card the UICC resides inside the mobile device. However, whereas the SIM is seen as the physical 
card together with the software to authenticate, authorize, and identify the subscriber, the UICC merely defines the 
physical characteristics of the smart card. The USIM and ISIM are seen as software applications resident on the UICC. 
As previously stated a USIM must be present and an ISIM may be present. 

The UICC should remain the property of the mobile network operator who will need to have the authority to decide as 
to which applications can reside on it, e.g. USIM, ISIM. 

NOTE: When accessing IMS over GERAN/UTRAN or I-WAN using ISIM, a USIM needs also to be present to 
access the rest of the 3GPP system. 

The general requirements being that the subscriber can be uniquely identifiable by the network, the service network can 
authenticate the subscriber, and that if a subscriber is being served by a network other than its home network, the 
visiting network shall be able to identify the associated home network. 

Clause 13 from TS 122 101 [5] provides further clarification of the USIM module and the ISIM module in relationship 
to the UICC. 

5.2 USIM 

USIM is an application and not an identifier, this application is to reside on the UICC module. The following is a 
summary of the requirements for the USIM application: 

Every USIM has a unique identifier and is associated with one and only one home network. 

It is possible for a home network to uniquely identify a subscription by the USIM. 

The USIM is used to provide security features. 

For access to services, provided by Packet Switched or Circuit Switched Core Networks, a valid USIM is 
required. 

The USIM resides on a UICC. USIM specific information is protected against unauthorized access or 
alteration. 

Access to the IMS services is possible using the USIM derived private identifier in the event of no ISIM being 
present on the UICC. If an ISIM is present on the UICC it is used to access the IMS. 

The specification does not preclude the support of more than one USIM per UICC associated with the same or different 
home networks so long as the security problems which arise from such coexistence are solved. However, only one 
USIM can be active at any given time. 

The USIM's private ID is based on the IMSI which contains the Mobile Network Code (MNC) allocated by the 
appropriate country's NRA. The IMSI (based on ITU-T Recommendation E.212 [9]) can be used for registering the user 
on Circuit Switched networks and Packet Switched networks. 

5.3 ISIM 

ISIM is an application and not an identifier, this application is optional to the UICC module. The following is a 
summary of the requirements for the ISIM application: 

Access to the IMS Domain is possible using an ISIM application. 

The ISIM is sufficient for providing the necessary security features for the IMS. 

The ISIM may reside on a UICC. ISIM specific information is protected against unauthorized access or 
alteration. 

It is recommended that the format of the identifier(s) stored in the ISIM are based on E.164 and/or E.212 resources. 
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The ISIM consist of Public ID(s), Private ID and Home Domain ID. The Home Domain ID provides the means by 
which that IMS routes a users" registration request to the Home IMS Network. The Private ID is how the user is 
authenticated by the user's Home IMS Network and the Public ID is how the user is contactable by other users for IMS 
based services. 

If there is no ISIM application, a backward compatibility mechanism is in place to derive the Home Network Domain 
name (ID)from the IMSI as described in the following steps: 

1) Take the first 5 or 6 digits, depending on whether a 2 or 3 digit MNC is used (see TS 131 102 [4] ) and 
separate them into MCC and MNC; if the MNC is 2 digits then a zero shall be added at the beginning. 

2) Use the MCC and MNC derived in step 1 to create the "mnc<MNC>.mcc<MCC>.3gppnetwork.org" Domain 
Name. 

3) Add the label "ims." to the beginning of the domain. 
An example of a Home Network Domain Name is: 

IMSI in use: 234150999999999; 

Where: 

MCC = 234; 

MNC = 15; 

MSIN = 0999999999, 

which gives the Home Network Domain Name: ims.mnc015.mcc234.3gppnetwork.org. 

NOTE 1: An MCC is assigned by the ITU-T to a member state. 

MNCs under this MCC are assigned by the NRA of this member state to an operator. 

MSINs are assigned by the operator to its customers. 

The use of the Home Domain Name works best in a globally agreed and unique domain name space which all operators 
(e.g. fixed and mobile) who need to use it can access directly. 

NOTE 2: Having to use the Domain Name '3gppnetwork.org' requires access to the 3GPP DNS system. The 
Domain Name 3gppnetwork.org is controlled by GSMA for registration in a private extranet. 

If there is no ISIM application, the private identifier is not known, in that case the private identifier could be derived 
from the IMSI (TS 123 003 [6] clause 13.3). However, this derived identifier is not visible for end-users and it is 
replaced by the actual public identifier obtained during the registration procedure (see GSMA IR.65 subclause 8.1, see 
bibliography) 

The following steps show how to build the Private Identifier out of the IMSI: 

1) Use the whole string of digits as the username part of the private identifier. 

2) Convert the leading digits of the IMSI, i.e. MNC and MCC, into a domain name, as described in clause 
6.2.1.1. 

The result will be a Private User identifier of the form "<IMSI>@ims.mnc<MNC>.mcc<MCC>. 3gppnetwork.org". For 
example: If the IMSI is 234150999999999 (MCC = 234, MNC = 15), the private user identifier then takes the form 
234150999999999@ims.mnc015.mcc234.3gppnetwork.org 

The private ID is used only in the Home Domain operator's network. 

The approach for 3GPP UEs roaming into the NGN is specified ( TS 123 003 [6] clause 13.2). 

The realm can take a number format as defined by the Home Domain operator , except in the case where the Private ID 
(containing the realm) is derived from the IMSI. The whole of the username @realm needs to be unique in the Home 
Domain operator's network. 
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5.4 Backward Compatibility 



3GPP have provided backward-compatibility with the UMTS Services Identity Module (USIM) and thus with IMSIs 
and MSISDN numbers. 

There are other identifiers that ETSI will need to address in time, but these ones are critical to the whole NGN structure 
and so are focussed on initially. 

Interoperabiltiy betweeen operators who specify their networks by reference to different families of standards, e.g. ETSI 
TISPAN or 3GPP, is an important issue. 

Future work must consider compatibility of identifiers in an environment where such interoperability occurs as there 
will be an evolution to a fully encompassing NGN. 



Concept on the use of IDs in NGN 



In principle, it should be possible for any user of the ISDN, PSTN, PLMN or an IP-based NGN network to identify 
users in a global basis. That implies that Public IDs are globally unique. 



6.1 



Introduction 



Due to the ubiquitous use of identifiers, the list below should not be considered as providing a complete list. 

Table 1 : Overview of Identifiers 





Public ID 
(User aware) 


Format of the Public 
ID within the network 


Private ID 
(Network Aware) 


NGN Layer 


User/Service 
Identifier 


Name(s) 


• SIP URI 


• ID stored in ISIIVI 


Service 


Number(s) 


• tel URI 

• SIP URI with 
domain operator- 
provided 


• ID stored in ISIIVI 
or derived from 
USIM 


Network Identifier 


Address 


• Number, and 
Routeing Number 

• IP Address 


• Networl< ID 

• Line ID 


Transport 



The format SIP URI and tel URI is a means to translate the identifiers used by the network in order to format E.164 
numbers in coherence with SIP protocol requirements, as described in table 1 . 

The NGN Layers are according to [16]: 

• Service Stratum/Layer 

The different services/applications are located here, together with the databases keeping the user related 
information and identifiers. 

• Transport Stratum/Layer 

This part provides for the transport of the media streams and also supports the users in gaining access to the 
applications and also control of resources and admissions. 

• Customer and Terminal functions 

This part covers the networking infrastructure at the user's premises. 
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Figure 3 shows the NGN stratum/layer (more generic than the figure contained in [16]. 
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Figure 3: Functional model of the TISPAN NGN 

Identifier required: 

User and NGN Terminals IDs. 

NASS IDs: see clause A.2.2. 

RACS IDs: see clause A.2.3. 

Use Data IDs: see clause A.2.1. 

IMS/PES IDs. 

Common components IDs (see [16] and [17]), are used by several subsystems, such as those required for 
accessing applications, charging functions, user profile management, security management, routeing data 
(e.g. ENUM), etc. 



6.2 



IDs used in TISPAN NGN 



To enable access to NGN using the existing mobile subscriptions (that are based only on USIM) also a mechanism to 
derive these values from USIM could be evaluated. This results in the requirement to support Home Domain Names in 
the 3GPP format based on the use of MNC, MCC. 

NOTE: If MNC and MCC are to be used by fixed network operators, this might require changes to national 
regulations. 
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6.2.1 IDs for Users 



An NGN operator can store User IDs in ISIMs provided to its subscribers or directly inside the terminals, if necessary. 
3GPP specify that the ISIM itself is made up of various attributes. The main 3GPP attributes used for registration and 
authentication are the Home Domain Name, the Public and the Private Identifier. These identifiers are explained below. 

6.2.1.1 Home Domain Name 

The Home Domain Name is used to identify the home domain of the user. This is used during authentication and 
registration. The format of the Home Domain Name is based on the Domain Name e.g. 'operator.com' as specified in 
RFC 1035 [2]. Note that there is no requirement for having the domain part of the private and public identifier being 
equal to this Domain Name since the two values are independent, but some operators may choose to link these two 
identifiers. 

The Home Network Domain Name is the parameter which is used to route the initial SIP registration requests to the 
home operator's IMS network. The Home Network Domain Name is stored in the ISIM. Upon receipt of the register 
information flow, the P-CSCF examines the Home Network Domain Name to discover the entry point to the home 
network (i.e. the I-CSCF). Note also that for the initial registration message routeing, the Domain Name resolution 
mechanism is made available to the user equipment at network attachment when the DHCP provides it with the domain 
name of a P-CSCF and the address of a Domain Name Server (DNS) that is capable of resolving that P-CSCF name: 

• e.g. if there is no ISIM application (i.e. when there is no IMS-specific module), the Home Domain Name must 
be derived from the data available "locally" to the UE. 

6.2.1 .2 Private User Identifiers 

Every NGN user has at least one private identifier. Private user identifiers are assigned by the home operator and are 
used to identify the IMS user's subscription. Its main role is to support the authentication procedure during 
registration/re-registration/de-registration, authorization, administration and accounting purposes at the home IMS. It is 
also used as the primary means of identifying the user within a dialog between network entities (e.g. UPSF or S-CSCF 
selection). The private user identifier is not used in SIP call routeing, but is conveyed in all registration requests. A 
private user identifier is "permanent" (i.e. not tied to a particular call instance/session.) and stored locally in the ISIM 
(IM Services Identity Module) that will be used to instantiate the registration message parameters. In some cases, the 
private user identifier may also be instantiated with default values when no ISIM is available. 
For its syntax, the private user identifier shall take the form of an NAI, and shall have the form username ©realm as 
specified in clause 2.1 of RFC 4282 [18] in accordance with TS 123 003 [6] and TS 123 228 [7]. In case there is no 
ISIM on the UICC, the private user ID is derived from the IMSI. The username is replaced with the complete IMSI 
value. However for the realm the Home Domain Name value is used. 

Further, there is no functional requirement for mandating a single private ID structure for a given IMS network. 

In IMS, the Home Domain Name, which is part of the private identifier, is used to route from a P-CSCF to the home 
operator's I-CSCF. 

6.2.1 .3 Public User Identifiers 

Every IMS user has one or more public identifiers, which are primarily used for user-to-user communication. The 
public identifier serves as a basis for message routeing, possibly after a translation mechanism when appropriate, both 
for IMS session-based SIP messages (e.g. INVITE) or off-session SIP messages (e.g. NOTIFY). There is at least one 
public identifier stored in the ISIM, but like the private identifier, in some cases, it may also be instantiated with default 
values when no such ISIM is available. Note also that public identifiers are not authenticated during registration, but the 
correspondence between private identifier and public identifier can be checked by the UPSF. 

For its syntax, the public identifier shall take the form of either a SIP URI or a tel URI. A SIP URI shall take the form 
"sip:user@domain" (TS 23.003 or TS 23.228). Note that tel URIs public user identifiers (whether they are based on 
E.164 (i.e. public) or private number) can not be used for SIP call routeing in IMS and must be translated in SIP URI 
using ENUM. 

Every IM CN subsystem user must have one or more public identifier(s). This identifier is used between users who wish 
to communicate with each other. Hence this identifier may be found on such items such as business card, web sites etc. 
It is the equivalent to how a web site or number is used today. However it should be noted that the number is not used to 
authenticate the user during registration. Neither is it used to identify the user's information within the UPSF. 
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A public user ID, e.g. stored on the ISIM, is needed by NGN to access ordinary services like e.g. E-mail, Instant 
messages. Access to e.g. emergency services may be possible without having a public user ID. 

The IMS Public User ID (IMPU) is in the format of a SIP URI. However both Internet naming and telephone 
numbering is supported, so technically the format is either a SIP URI, or a tel URI. At least one IMPU is stored on the 
ISIM and cannot be modified by the UE. However, additional IMPUs do not have to be stored on the ISIM, although it 
is recommended. 

The IMPU can be registered either explicitly or implicitly, but must be registered before the identifier can be used to 
originate IMS sessions and IMS session unrelated procedures. The identifier also has to be registered, either explicitly 
or implicitly, before terminating IMS sessions. 

If a UICC is used that does not contain an ISIM then a temporary IMPU can be derived from the USIM's IMSI and used 
for the initial SIP registration process only. The temporary IMPU takes the format of a SIP URI. The format is as 
follows: 

SlP:<private user identified; 

where <private user identifier> is derived as described in clause 6.2.1.2. 

NOTE: The ISIM does not need to reside on a UICC for ETSI NGN purposes. 

The UPSF provides a public user ID to the user which will be used in the subsequent messages in the 'FROM' field of 
the SIP INVITE message. As a consequence, the temporary IMPU will never be displayed at the called party's UE. 



6.2.1.4 



Relationship of Private and Public IDs 



An important starting point is to consider the main IDs used by 3GPP IMS and their relationships in the key IMS 
databases. These issues are considered in clause 4.3.3.4 of TS 123 228 [7] as endorsed by TISPAN in TS 182 006 [19], 
where object diagrams illustrate some of the required relationships. 
For ease of reference the figures 4.5 and 4.6 of TS 123 228 [7] are reproduced below. 
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Figure 4: Relationship between the Private User Identity and Public User Identities 

Public user identities may be shared across multiple Private User Identities within the same IMS subscription. Hence, a 
particular Public User Identity may be simultaneously registered from multiple UEs that use different Private User 
Identities and different contact addresses. If a Public User Identity is shared among the Private User Identities of a 
subscription, then it is assumed that all Private User Identities in the IMS subscription share the Public User Identity. 

The relationship for a shared Public User Identity with Private User Identities, and the resulting relationship with 
service profiles and IMS subscription, is depicted in figure 5. 
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Figure 5: The relation between a shared Public User Identity (Public-ID-2) and Private User Identities 

In particular, clause 4.3.3.4 of TS 123 228 [7] identifies that the combination of the Private ID and the Public ID is used 
to register the users" details to their allocated S-CSCF from their HSS User Profile. 

As well as the Public ID used for registration, more Public IDs can be registered and stored in the S-CSCF during this 
process. Each Public ID is associated with one and only one Service Profile (from clause 4.3.3.4 in TS 123 228 [7]), 
though a Service Profile can be associated with many public IDs. 

Another valuable, though different description of the object relationships is provided for when user data structures are 
passed from the HSS to the S-CSCF. These are described in the UML in TS 129 228 [8]. These descriptions are not 
necessarily incompatible, since the data structures passed from the HSS to the S-CSCF are a description of the IDs 
required for session/call processing, not of the full underlying structure of the database. 

These 3GPP descriptions are not necessarily incompatible, since the data structures passed from the HSS to the S-CSCF 
are a description of the IDs required for session/call processing, not of the full underlying structure of the database. 

The implication of the UML in TS 129 228 [8] is that at any one time, only one private ID represents the user for 
session/call processing. In 3GPP the private ID could only be used to register one single user equipment at one instance 
of time, whereas in NGN a multiplicity of user equipment should be allowed to use the same private ID for concurrent 
registration. Thus this conflicts with TISPAN requirements to use private IDs to represent different user roles or for 
registering from different equipment simultaneously and needs further investigation. 

It should be possible to change the private ID without changing the public ID allocated to a subscriber and vice versa. 



6.2.1.5 



Handling of dialled number formats 



The user may use E.164 numbers in local, national or international format. Whenever possible the dialling sequence 
must be converted into E.164 international numbering format to allow for ENUM lookup. When this is not possible the 
URI should specify the nature of the format of the sequence of digits that is being conveyed by the URL 



6.2.1.6 



Termination of session with the tel URI format Public User ID 



If in a terminating session a tel URI is used, the UPSF and the SLF (in the case that more than one independently 
addressable UPSF is utilized by a network operator) shall support the tel URI format Public User Identifier. 

6.2.2 Access IDs in the NGN 

The Access up to the User Entity is identified using: 

• Identifier for the Access Network. 

• Identifier for the Termination Point of the Physical Transport on the Access Network (e.g. Access Link). 

• Identifier(s)for the Logical Channel (possibly recursive). 

• Identifier(s) for the User Entities (UE) using the same Logical Channel. 
Figure 6 shows a simplified view of the above. 
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Figure 6: Relation between Access Link, Logical Channel, User Equipment 

In later TISPAN Releases the above nested structure of identifiers needs to be supported. 

In TISPAN Release 1 Access network level registration involves the access authentication which is authentication and 
authorization procedures between the UE and the NASS to control the access to the access network. Two authentication 
types are considered for access networks: implicit authentication and explicit authentication. 

• Explicit authentication is an authentication procedure that is explicitly conducted between the UE and the 
NASS. It requires a signalling procedure to be performed between the UE and the NASS. 

• Implicit authentication does not require the NASS to explicitly conduct an authentication procedure directly 
with the UE, however the NASS performs the implicit authentication based on identification of the L2 
connection the UE is connected to. 

It is a matter of operator policy whether impUcit authentication or explicit authentication is applied. 

There shall be mutual authentication between the UE and the NASS [14] during access network level registration. 

Both implicit authentication and explicit authentication may be used independently as network level access 
authentication mechanism, notwithstanding the fact that implicit authentication may be a consequence of explicit 
authentication (e.g. the implicit line authentication used together with an explicit method such as Point-to-Point 
Protocol (PPP) RFC 1661 (see bibUography) in xDSL access). 

Authentication between users/subscribers and application/service providers shall be expUcit or implicit (based on 
trust/security assertions). 

Through the Network Attachment Subsystem it is possible to: 

• Provide registration at access level and initiaUzation of User Equipment (UE) for accessing to the TISPAN 
NGN services. 

• Provide dynamic provisioning of IP address and other user equipment configuration parameters (e.g. using 
DHCP). 

• Authenticate the user, prior or during the IP address allocation procedure. 

• Authorize of network access, based on user profile. 

• Access network configuration, based on user profile. 

• Location management. 

The Network Access Configuration Function (NACF) is responsible for the IP address allocation to the UE. It may also 
distribute other network configuration parameters such as address of DNS server(s), address of signalling proxies for 
specific protocols (e.g. address of the P-CSCF when accessing to the IMS). 

The NACF should be able to provide to the UE an access network identifier. This information uniquely identifies the 
access network to which the UE is attached. 
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The Connectivity Session Location and Repository Function (CLF) registers the association between the IP address 
allocated to the UE and related network location information provided by the NACF, i.e.: access transport equipment 
characteristics, line identifier (Logical Access ID), IP Edge identity, etc. The CLF interfaces with the NACF to get the 
association between the IP address allocated by the NACF to the end user equipment and the Line ID. The CLF 
responds to location queries from service control subsystems and applications. The actual information delivered by the 
CLF may take various forms (e.g. network location, geographical coordinates, post mail address, etc.), depending on 
agreements with the requestor and on user preferences regarding the privacy of its location. The CLF holds a number of 
records representing active sessions. 

The definition of this format shall also be lined up with OCG EMTEL who has decided that the LIE (Location 
Information Forum) is required in certain environments according to regulatory requirements. 

Correct operation of a 3GPP IMS based network requires a number of different identifiers to be present in the IMS. The 
key identifiers, together with the role they fulfil in NGNs and how they come to be present in the system, are shown in 
table 2. 

Table 2: Overview showing thie role of different identifiers and associated handling 



Identifier 


Role within 3GPP 


Method of provisioning 3GPP 


Method of provision for fixed 
line access 


IP address 


Used to support media and 
signalling stream 


Downloaded into terminal from 
DHCP in access network and 
uploaded to S-CSCF as part of 
registration process 


Associated with line card as 
part of service provision 
process 


Private identifier 


To identify terminal to system 
as part of registration / 
authentication process. Also 
used for billing 


Held in ISIIVI explicitly or 
derived from USIIVI, then loaded 
into S-CSCF via registration 
process. 


'Pseudo IIVISI' provided and 
held in UPSF as part of service 
provision process 


Public identifier 


Used to identify required 
terminal on incoming calls. Also 
used as CLI on outgoing calls 


Programmed into ISIM and 
loaded into HSS as part of 
service provision process. 


Programmed into UPSF as part 
of service provision process. 



6.2.3 Identification of Network Nodes 

The CSCE, BGCF and MGCF nodes (functionaUties I-BCF and IBGF) shall be identifiable using a vaUd SIP URI (Host 
Domain Name or Network Address) on those interfaces supporting the SIP protocol, (e.g. Gm, Mw, Mm, and Mg). 
These SIP URIs would be used when identifying these nodes in header fields of SIP messages. The names should be 
allocated in the public DNS system, however, this does not require that the nodes be reachable from the global Internet. 
These URIs will not be resolvable via the public DNS, they will only resolve from within the operators' network. 

Globally unique identifiers for certain network elements (e.g. x-CSCEs) will be required so that a shared interconnect 
model, e.g. a GRX/IPX type interconnect model can be supported. Element identifier can be left to the choice of the 
service provider since the operator identifier and root domain uniquely identify the service provider. However the 
element name should be compliant with RFC 1093 [13] and it is possible that further constraints, yet to be identified, 
may be required. 

6.2.4 IDs for Services 

Public Service Identifiers shall take the form as defined in TS 123 003 [6]. 

All public service identifiers need to meet the specific requirements of services such as: 

• Voice. 

• Instant Messaging Service. 

• Presence Service. 

• Location Service. 

The public service identifier shall take the form of either a SIP URI (see RFC 3261 [11]) or a tel URI (see 
RFC 3966 [3]). 
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A public service identifier defines a service, or a specific resource created for a service. 

The domain part is pre-defined by the NGN operators and the IMS system provides the flexibihty to dynamically create 
the user part of the PSIs. 

The SIP URI shall take the form of a distinct PSI "SIP:service@domain", where 'service' identifies a service. 

EXAMPLE: sip:conference@examplenetwork.com. 

Generally for SIP URIs three different contexts have to be differentiated: 

• international E.164 number; 

• private number which must include a context; 

• short codes. 



6.2.5 IDs for NGN operators 

Proposals have been made for a naming scheme for NGN network elements. This takes the format <element 
id>.<service provider>.<root domain>. The nature of the root domain needs further consideration in the light of recent 
initiatives outside ETSI (e.g. GSMA). However there is general agreement that this needs to be allocated from within 
the public DNS name space. A name per operator/service provider will need to allocated, and this must be unique 
within the root domain if misrouteing is to be avoided. To ensure that uniqueness is achieved, the entity responsible for 
governance of the route domain will need to be responsible for allocation of SP identifiers. A user friendly name for the 
root domain is favourable. 

Additional requirements may occur in the situation, where same services are supplied to the user from different service 
providers. In such circumstances separate public service provider identifiers would be required and must be supported 
by the NGN. 

6.3 ID translation in NGN 

Identifiers are used throughout the network to identify sources/destinations of traffic and also resources within the 
network. One special kind of identifier is an E. 164 number that is used by PSTN users to identify the destination of a 
call. In the context of an NGN, E.164 numbers need to be translated into an identifier format usable within the NGN. 

6.3.1 E.1 64 to SIP URI translation for routeing (ENUM) 

There is currently no decision that the public DNS/ENUM as specified in RFC 3761 [12] be used. This topic is for 
further study. 

In some cases when the subscriber provided an E. 164 number only, 3GPP foresees an E. 164 to SIP URI translation 
especially if the requested E. 164 number is not under control of the IMS (e.g. in the case of Interconnection). 

Case 1: derived according to TS 123 228 [7] 

In the case where the Request-URI of the incoming INVITE request to S-CSCF contains a tel URI [3], it has to be 
translated to a globally routable SIP-URI before applying it as Request-URI of the outgoing INVITE request. For this 
address translation the S-CSCF uses the services of an ENUM-DNS protocol based on to RFC 3761 [12]. Database 
aspects of ENUM are outside the scope of this specification. 

Case 2: derived according to TS 122 228 [1] 

The S-CSCF shall support the ability to translate the E.164 number contained in a Request-URI in the non-SIP URI 
Tel: URI format RFC 3966 [3] to a SIP routable SIP URI using an ENUM DNS translation mechanism based on 
RFC 3761 [12]. If this translation fails, then the session may be routed to the PSTN or appropriate notification shall be 
sent to the mobile, depending on network operator configuration. 
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Case 3: derived according to TS 123 228 [7] 



An Application Service (AS) is hosting Public Service IDs (PSI) and may originate requests with the PSI as the 
originating party. For such originating requests, the home IMS network shall be capable to perform the following 
function: 

If the target identifier is a tel URI, ENUM translation needs to be performed, and the request shall be routed 
based on the translation result. 

Routeing from the Originating AS hosting the PSI can be performed as follows: 

a) The AS may forward the originating request to the destination network without involving an S-CSCF. If this 
option is applied where the target identifier is a tel URI, the AS shall perform an ENUM query and route the 
request based on the translation result. ENUM support for an AS is optional, therefore, if an AS does not 
support ENUM and the target identifier is a tel URI, it shall be configured to use b). 

b) If the PSI has an S-CSCF assigned, the AS forwards the originating request to this S-CSCF, which then 
processes the request as per regular originating S-CSCF procedures (including a possible DNS/ENUM query). 

6.3.2 Accessibility of ID Translation 

TISPAN NGN supports the E.164 number translation based on RFC 3966 [3] for routeing. 

3GPP tackles the critical issue of how tel URIs should be used for IMPUs. In particular, for routeing, tel URIs are 
translated into SIP URIs. This highlights the importance of the location of such an Infrastructure ENUM DNS 
translation mechanism. This translation mechanism can be located in: 

1) Publicly accessible DNS; or 

2) Private DNS. 

In the first case this is based on RFC 3966 [3]. In the second case this routeing data tree will only be accessible by a 
single or a group of cooperating operators and needs only to be agreed between the participating operators. 



Administration of NGN IDs 



Identifiers fall into 3 classes (not mutually exclusive): 

• Those generated automatically by network elements (e.g. call identifiers). For these, no human intervention is 
required (or possible). 

• Those that may be allocated by operators without reference to external bodies (e.g. customer account number). 

• Those for which operators must go to external bodies (e.g. NRA and others) to receive allocations (e.g. E.164 
numbers, public IP addresses). 

Framework Directive, Article 10.1 (see bibliography) requires that National regulatory authorities control the 
assignment of all national numbering resources and the management of the national numbering plans. Adequate 
numbers and numbering ranges shall be provided for all publicly available electronic communications services. 

Framework Directive, Article 10.1 (see bibliography) also requires that National regulatory authorities establish 
objective, transparent and non-discriminatory assigning procedures for national numbering resources. 

7.1 Overview on administration 
7.1.1 E.164 Numbers 

According to the WTSA, ITU-T Study Group 2 ('SG2') is the lead ITU-T Study Group with regard to the 
Administration of International Numbering Resources. SG2's responsibilities, under this mandate, include overseeing 
the administration of all such resources in order to ensure uniformity and equity in their assignment, despite the 
technical responsibilities for these resources being dispersed across multiple ITU-T Study Groups. 
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Specifically, ITU-T Recommendation E. 164 [10], defines the number structure and fiinctionality for four principal 
categories of numbers used for international public telecommunication - namely geographic areas. Global Services, 
Networks, and Groups of Countries ('GoCs'). For each of the categories. Recommendation E.164 details the 
components of the numbering structure and the digit analysis required to successfully route calls. Other specific 
Recommendation E. 164-based global service applications (e.g. Universal International Freephone Numbers), which 
differ in usage, are defined in separate ITU-T Recommendations related to E.164, include, inter alia: 

• ITU-T Recommendation E. 164.1 [20]: "Criteria and procedures for the reservation, assignment and 
reclamation of E.164 country codes and associated Identification Codes (ICs)"; 

• ITU-T Recommendation E. 164.2 [21]: "E.164 numbering resources for trials"; 



• 



• 



Determined ITU-T Recommendation E. 164.3 [22]: "Principles, criteria and procedures for the assignment and 
reclamation of E.164 country codes and associated identification codes for Groups of Countries"; 

ITU-T Recommendation E.190 [23]: "Principles and responsibilities for the management, assignment and 
reclamation of E-series international numbering resources"; 



• ITU-T Recommendation E.195 [24]: "ITU-T International numbering resource administration". 

7.1.2 IP Addresses 

Currently there are two types of Internet Protocol (IP) addresses in active use: IP version 4 (IPv4) and IP version 6 
(IPv6). IPv4 was initially deployed on 1 January 1983 and is still the most commonly used version. IPv4 addresses are 
32-bit numbers often expressed as 4 octets in "dotted decimal" notation (for example, 192.0.32.67). Deployment of the 
IPv6 protocol began in 1999. IPv6 addresses are 128-bit numbers and are conventionally expressed using hexadecimal 
strings (for example, 1080:0:0:0:8:800:200C:417A). 

Both IPv4 and IPv6 addresses are assigned in a delegated manner. Users are assigned IP addresses by Internet service 
providers (ISPs). ISPs obtain allocations of IP addresses from a local Internet registry (LIR) or national Internet registry 
(NIR), or from their appropriate Regional Internet Registry (RIR): 

AfriNIC (African Network Information Centre) - Africa Region 

APNIC (Asia Pacific Network Information Centre) - Asia/Pacific Region 

ARIN (American Registry for Internet Numbers) - North America Region 

LACNIC (Regional Latin- American and Caribbean IP Address Registry) - Latin America and some Caribbean 
Islands 

RIPE NCC (Reseaux IP Europeens) - Europe, the Middle East, and Central Asia 

The IAN A's role is to allocate IP addresses from the pools of unallocated addresses to the RIRs according to their 
established needs. When an RIR requires more IP addresses for allocation or assignment within its region, the lANA 
makes an additional allocation to the RIR. 

Important hnks: 

• IPv4 Address Space 
( http://www.iana.org/assignments/ipv4-address-space ) 

• IPv6 Address Allocation and Assignment Policy 
( http://www.iana.org/ipaddress/ipv6-allocation-policy-26iun02 ) 

• IPv6 Address Space 
( http://www.iana.org/assignments/ipv6-address-space ) 
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7.1.3 Domain Names 



The Domain Name System (DNS) helps users to find their way around the Internet. Every computer on the Internet has 
a unique address -just like a telephone number - which is a rather complicated string of numbers: the IP address. 
However IP addresses are hard to remember. The DNS makes using the Internet easier by allowing a familiar string of 
letters (the "Domain Name") to be used instead of the arcane IP address. 

The Internet Corporation for Assigned Names and Numbers (ICANN - www.icann.org ) is an internationally organized, 
non-profit corporation that has responsibility for gTLD and ccTLD name system management. 

The responsibility for operating each TLD (including maintaining a registry of the Domain Names within the TLD) is 
delegated by ICANN to a particular organization. These organizations are referred to as 'registry operators'. Currently, 
the gTLD of .aero, .biz, .com, .coop, .info, .museum, .name, .net, .org and .pro are in use, and the corresponding 
registries are under contract with ICANN. Separate arrangements apply to .edu, .mil, .gov, under United States 
Government responsibility, and .int which is directly under ICANN's responsibility. 

Domain Names can be registered through many companies known as "registrars". The registrar collects various contact 
and technical information that makes up the user's registration. The registrar keeps then records of the contact 
information and submit the technical information to the registry operator. The latter provides other computers on the 
Internet the information necessary to resolve the Domain Name in the correct IP address. 

SIP addresses used as public user ID in NGN are based on Domain Names. A SIP address (or a SIP URI) is a type of 
Uniform Resource Identifier that identifies a communication resource in SIP. A SIP URI usually contains a user name 
and a host name and is similar in format to an email address (example: user@domain.foo). 

7.1 .4 International Mobile Subscriber Identity - IMSI 
(ITU-T Recommendation E.212) 

The IMSI is a string of decimal digits, up to a maximum of 15 digits, that identifies a unique mobile terminal or mobile 
subscriber internationally. IMSIs may also be used for terminal or subscriber identification within fixed or wireline 
networks that offer mobility services, or to achieve compatibility with networks that have mobility services. The IMSI 
consists of three fields: the MCC, the MNC, and the MSIN. The IMSI conforms to the ITU-T Recommendation for 
E.212 numbering. 

MCCs are assigned by the ITU in response to formal requests from national administrators of ITU Member States. 
Additional MCCs will be assigned only in anticipation of exhaust of assigned code(s). MNCs are administered by the 
designated administrator within each country or by the TSB in the case of shared MCCs. Additional MNCs are assigned 
to MNC assignees within a shared MCC only for exhaust of the assigned code(s). MSINs are administered by the MNC 
assignee. 

In principle, only one IMSI shall be assigned to each mobile terminal or mobile user. In case of multiple subscriptions 
(subscriptions to more than one mobility service from one or more service providers), a mobile terminal or mobile user 
may be assigned a different IMSI for each subscription. 
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Annex A (normative): 
3GPP and TISPAN IDs 

A.1 Identifiers already defined in 3GPP 



Identifier 
name 


Clause in 
[6] 


Definition in TS 123 003 [6] 


TISPAN statements 




2 


Identification of mobile subscribers 




IMSI 


2.2 


A unique International Mobile Subscriber Identity (IIVISI) shall be 
allocated to each mobile subscriber in the GSM/UMTS system. 


Not used within NASS 


TMSI 


2.4 


In order to support the subscriber identity confidentiality service the 
VLRs and SGSNs may allocate Temporary Mobile Subscriber 
Identities (TMSI) to visiting mobile subscribers. The VLB and 
SGSNs must be capable of correlating an allocated TMSI with the 
IMSI of the MS to which it is allocated. 


Not used within NASS 


P-TMSI 


2.1 


Packet TMSI 

An MS may be allocated two TMSIs, one for services provided 
through the MSG, and the other for services provided through the 
SGSN (P-TMSI for short). 


Not used within NASS 


TLLI 


2.6 


For addressing on resources used for GPRS, a Temporary Logical 
Link Identity (TLLI) is used. The TLLI to use is built by the MS 
either on the basis of the P-TMSI (local or foreign TLLI), or directly 
(random TLLI). 


Access network type 
specific (ID specific to 
3GPP networks) 


LMSI 


2.5 


In order to speed up the search for subscriber data in the VLR a 
supplementary Local Mobile Station Identity (LMSI) is defined. 
The LMSI may be allocated by the VLR at location updating and is 
sent to the HLR together with the IMSI. The HLR makes no use of it 
but includes it together with the IMSI in all messages sent to the 
VLR concerning that MS. 


Access network type 
specific (ID specific to 
3GPP networks) 


NRI 


2.4 


Network Resource Identifier 

If intra domain connection of RAN nodes to multiple ON nodes as 
described in 3GPP TS 23.236 is applied in the MSC/VLR or SGSN, 
then the NRI shall be part of the TMSI. The NRI has a configurable 
length of to 10 bits. A configurable length of bits indicates that 
the NRI is not used and this feature is not applied in the MSC/VLR 
or SGSN. The NRI shall be coded in bits 23 to 14. An NRI shorter 
than 10 bits shall be encoded with the most significant bit of the NRI 
field in bit 23. 


Access network type 
specific (ID specific to 
3GPP networks) 




3 


Numbering plan for mobile stations 




MSISDN 


3.3 


Mobile station international PSTN/ISDN number (E.I 64) 

The number consists of: 

Country Code (CC) of the country in which the MS is 

registered, followed by: 

National (significant) mobile number, which consists of: 

National Destination Code (NDC); and 

Subscriber Number (SN). 


A number of this 
format (i.e. an E.I 64 
number) is required for 
NGNs, however, the 
term MSISDN is 3GPP 
specific 


MSRN 


3.4 


Mobile station roaming number for PSTN/ISDN routeing (E.I 64) 

The Mobile Station Roaming Number for PLMN/ISDN routing shall 
have the same structure as MSISDN numbers in the area in which 
the roaming number is allocated. 


Needed only in a 
circuit switched 
environment 




3.5 


Mobile station international data number 

The structure of MS international data numbers should comply with 
the data numbering plan of ITU-T Recommendation X.I 21 as 
applied in the home country of the mobile subscriber. 


Not needed, as all 
services can be 
provided using the 
same number 




3.6 


Handover number 

The structure of the handover number Is the same as the structure 
of the MSRN. 


Handover implies 
"session continuity" 
which is for further 
study (ffs) in TISPAN 
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Identifier 
name 


Clause in 
[6] 


Definition in TS 123 003 [6] 


TISPAN statements 




4 


Identification of location areas and base stations 




LAI 


4.1 


Location Area Identity 

The LAI is composed of the following elements: 

IVIobile Country Code (MCC) identifies the country in which 
the GSM PLIVIN is located. The value of the IVICC is the 
same as the three digit IVICC contained in international 
mobile subscriber identity (IMSI); 

Mobile Network Code (MNC) is a code identifying the GSM 
PLMN in that country. The MNC takes the same value as 
the two or three digit MNC contained in IMSI; 
Location Area Code (LAC) is a fixed length code (of 2 
octets) identifying a location area within a PLMN. This part 
of the location area identification can be coded using a full 
hexadecimal representation except for the following 
reserved hexadecimal values: 

0000, and 
- FFFE. 

These reserved values are used in some special cases when 
no valid LAI exists in the MS (see 3GPP TS 24.008 , 
3GPP TS 31 .1 02 and 3GPP TS 51 .01 1 ). 


Access network type 
specific (ID specific to 
3GPP networks). 


RAI 


4.2 


Routing Area Identity 

The RAI is composed of the following elements: 

A valid Location Area Identity (LAI) as defined in clause 4.1. 
Invalid LAI values are used in some special cases when no 
valid RAI exists in the mobile station (see 3GPP TS 24.008 , 
3GPP TS 31 .1 02 and 3GPP TS 51 .01 1 ). 
Routeing Area Code (RAC) which is a fixed length code (of 
1 octet) identifying a routeing area within a location area. 


Access network type 
specific (ID specific to 
3GPP networks) 


CI 


4.3.1 


The BSS and cell within the BSS are identified within a location area 
or routeing area by adding a Cell Identity (CI) to the location area or 
routeing area identification, as shown in figure 5. The CI is of fixed 
length with 2 octets and it can be coded using a full hexadecimal 
representation. 


Access network type 
specific (ID specific to 
3GPP networks) 


CGI 


4.3.1 


The Cell Global Identification is the concatenation of the Location 
Area Identification and the Cell Identity. Cell Identity shall be unique 
within a location area. 


Access network type 
specific (ID specific to 
3GPP networks) 


BSIC 


4.3.2 


The Base Station Identity Code is a local colour code that allows 
an MS to distinguish between different neighbouring base stations. 
BSIC is a 6 bit code which is structured as shown in figure 6. 


Access network type 
specific (ID specific to 
3GPP networks) 


RSZI 


4.4 


A PLMN-specific regional subscription defines unambiguously for 
the entire PLMN the regions in which roaming is allowed. It consists 
of one or more regional subscription zones. The regional 
subscription zone is identified by a Regional Subscription Zone 
Identity (RSZI). A regional subscription zone identity is composed 
as shown in figure 7. 


Access network type 
specific (ID specific to 
3GPP networks) 




5 


Identification of MSCs, GSNs and location registers 




GSN address 


5.1 


GSN: GPRS Support Node address 
SGSN: Serving GPRS Support Node 
GGSN: Gateway GPRS Support Node 

MSCs, GSNs and location registers are identified by international 
PSTN/ISDN numbers and/or Signalling Point Codes ("entity 
number", i.e., "HLR number", "VLR number", "MSC number", "SGSN 
number" and "GGSN number") in each PLMN. 
Additionally SGSNs and GGSNs are identified by GSN Addresses. 
These are the SGSN Address and the GGSN Address. 


Access network type 
specific (ID specific to 
3GPP networks) 
(similar functionalities 
required in TISPAN to 
identify the access to 
the NGN) 


HLRID 


5.2 


Home Location Register 

HLR may also be identified by one or several "HLR id(s)", consisting 
of the leading digits of the IMSI (MCC + MNC + leading digits of 
MSIN). 


Not needed in TISPAN 

Release 1 

ffs for later releases 
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Identifier 
name 


Clause in 
[6] 


Definition in TS 123 003 [6] 


TISPAN statements 




6 


International Mobile Station Equipment Identity and Software 
Version Number 




IMEI 


6.2.1 


International Mobile Equipment Identity 

The IMEI is composed of the following elements (each element shall 
consist of decimal digits only): 

Type Allocation Code (TAG). Its length is 8 digits; 

Serial Number (SNR) is an individual serial number uniquely 

identifying each equipment within the TAG. Its length is 6 

digits; 

Spare digit: this digit shall be zero, when transmitted by the 

MS. 


Fixed network 
terminals need not to 
contain that ID 
ffs in later releases 


IMEISV 


6.2.2 


International Mobile Equipment Identity and Software Version 
Number 

The IMEISV is composed of the following elements (each element 
shall consist of decimal digits only): 

Type Allocation Gode (TAG). Its length is 8 digits; 

Serial Number (SNR) is an individual serial number uniquely 

identifying each equipment within the TAG. Its length is 6 

digits; 

Software VErsion Number (SRV) identifies the software 

version number of the mobile equipment. Its length is 2 

digits. 


Fixed network 
terminals need not to 
contain that ID 
ffs in later releases 




7 


Identification of Voice Group Call and Voice Broadcast Call 
Entities 




VGCS Group 

ID 
VBS Group ID 


7.3 


Logical groups of subscribers to the Voice Group Call Service or to 
the Voice Broadcast Service are identified by a Group Identity 
(Group ID). Group IDs for VGGS are unique within a PLMN. 
Likewise, Group IDs for VBS are unique within a PLMN. However, 
no uniqueness is required between the sets of Group IDs. These 
sets may be intersecting or even identical, at the option of the 
network operator. 


Access network type 
specific (ID specific to 
3GPP networks) 


Group Call 
Area Identity 


7.3 


Grouping of cells into specific group call areas occurs in support of 
both the Voice Group Gall Service and the Voice Broadcast Service. 
These service areas are known by a "Group Call Area Identity" 
(Group Gall Area Id). No restrictions are placed on what cells may 
be grouped into a given group call area. 


Access network type 
specific (ID specific to 
3GPP networks) 




9 


Definition of Access Point Name 




APN Network 
Identifier 


9.1 


Access Point Name 

The APN Network Identifier; this defines to which external network 
the GGSN is connected and optionally a requested service by the 
MS. This part of the APN is mandatory. 


Not needed in TISPAN 

Release 1 

ffs in later releases 


APN Operator 
Identifier 


9.1.2 


The APN Operator Identifier; this defines in which PLMN GPRS 
backbone the GGSN is located. This part of the APN is optional. 


Not needed in TISPAN 

Release 1 

ffs in later releases 




10 


Identification of Cordless Telephony System Entities 




FPBI 


10.3 


Every GTS-FP broadcasts a local identity - the Fixed Part Beacon 
Identity (FPBI) - which contains an Access Rights Identity. Every 
GTS-MS has both an Access Rights Key and a GTS Mobile 
Subscriber Identity (GTSMSI). These operate as a pair. A GTS-MS 
is allowed to access any GTS-FP which broadcasts an FPBI which 
can be identified by any of the GTS-MS Access Rights Keys of that 
GTS-MS. The GTS-MS Access Rights Key contains the FPBI and 
the FPBI Length Indicator (FLI) indicating the relevant part of the 
FPBI used to control access. 


Access network type 
specific (ID specific to 
Cordless Telephony 
Systems) 


GTSMSI 


10.2 


Each GTS-MS has one or more temporary identities which are used 
for paging and to request access. The structure and allocation 
principles of the CTS Mobile Subscriber Identities (GTSMSI) are 
defined below. 


Access network type 
specific (ID specific to 
Cordless Telephony 
Systems) 
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Identifier 
name 


Clause in 
[6] 


Definition in TS 123 003 [6] 


TISPAN statements 


IFPEI 


10.4 


The International Fixed Part Equipment Identity (IFPEI) is 
composed of tine following elements (each element shall consist of 
decimal digits only): 

Type Approval Code (TAG). Its length is 6 decimal digits; 

Final Assembly Code (FAC). Its length is 2 decimal digits; 

Serial NumbeR (SNR). Its length is 6 decimal digits; 

Software Version Number (SVN) identifies the software 

version number of the fixed part equipment. Its length is 2 

digits. 


Access network type 
specific (ID specific to 
Cordless Telephony 
Systems) 


IFPSI 


10.5 


The International Fixed Part Subscriber Identity (IFPSI) is 
composed of the following elements (each element shall consist of 
decimal digits only): 

Mobile Country Code (MCC) consisting of three digits. The 

IVICC identifies the country of the CTS-FP subscriber (e.g. 

208 for France); 

CTS Operator Number (CON). Its length is three digits; 

Fixed Part Identification Number (FPIN) identifying the 

CTS-FP subscriber.. 


Access network type 
specific (ID specific to 
Cordless Telephony 
Systems) 


NFPSI 


10.5 


The National Fixed Part Subscriber Identity (NFPSI) consists of 
the CTS Operator Number and the Fixed Part Identification Number. 


Access network type 
specific (ID specific to 
Cordless Telephony 
Systems) 




11 


Identification of Localised Service Area 




LSAID 


11 


Cells may be grouped into specific localised service areas. Each 
localised service area is identified by a Localised Service Area 
IDentity (LSA ID). No restrictions are placed on what cells may be 
grouped into a given localised service area. 
The LSA ID can either be a PLIVIN significant number or a universal 
identity. This shall be known both in the networks and in the SIM. 


Access network type 
specific (ID specific to 
3GPP networks) 




12 


Identification of PLMN, RNC, Service Area, CN domain and 
shared network Area 




PLMN-ID 


12.1 


A PLMN is uniquely identified by its Public Land Mobile Network 
Identifier. PLMN-ld consists of Mobile Country Code (MCC) and 
Mobile Network Code (MNC). 

PLMN-ld = MCC II MNC 


Operator network type 
specific 


CN Domain ID 


12.2 


Core Network Domain Identity 

A CN Domain Edge Node is identified within the UTRAN by its CN 
Domain Identifier. The CN Domain identifier is used over UTRAN 
interfaces to identify a particular CN Domain Edge Node for 
relocation purposes. The CN Domain identifier for Circuit Switching 
(CS) consists of the PLMN-ld and the LAC, whereas for Packet 
Switching (PS) it consists of the PLMN-ld, the LAC, and the RAC of 
the first accessed cell in the target RNS. 
The two following CN Domain Identifiers are defined: 
CN CS Domain-Id = PLMN-ld || LAC 
CN PS Domain-Id = PLMN-ld || LAC || RAC 


Access network type 
specific (ID specific to 
3GPP networks) 


CN ID 


12.3 


Core Network Identity 

A CN node is uniquely identified within a PLMN by its CN Identifier 

(CN-ld). The CN-ld together with the PLMN identifier globally 

identifies the CN node. The CN-ld together with the PLMN-ld is used 

as the CN node identifier in RANAP signalling over the lu interface. 

Global CN-ld = PLMN-ld || CN-ld 

The CN-ld is defined by the operator, and set in the nodes via O&M. 


Access network type 
specific (ID specific to 
3GPP networks) 
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Identifier 
name 


Clause in 
[6] 


Definition in TS 123 003 [6] 


TISPAN statements 


RNC-ld 


12.4 


Radio Network Controller Identity 

An RNC node is uniquely identified by its RNC Identifier (RNC-ld). 
The RNC-ld of an RNC is used in the UTRAN, in a GERAN which is 
operating in GERAN lu mode and between them. A BSC which is 
part of a GERAN operating in lu mode is uniquely identified by its 
RNC Identifier (RNC-ld). The RNC-ld of a BSC is used in a GERAN 
which is operating in GERAN lu mode, in the UTRAN and between 
them. RNC-ld together with the PLIVIN identifier globally identifies 
the RNC. The RNC-ld on its own or the RNC-ld together with the 
PLIVIN-ld is used as the RNC identifier in the UTRAN lub, lur and lu 
interfaces. The SRNC-ld is the RNC-ld of the SRNC. The C-RNC-ld 
is the RNC-ld of the controlling RNC. The D-RNC-ld is the RNC Id of 
the drift RNC. 

Global RNC-ld = PLMN-ld || RNC-ld 
The RNC-ld is defined by the operator, and set in the RNC via O&IVI. 


Access network type 
specific (ID specific to 
3GPP networks) 


SAI 


12.5 


The Service Area Identifier (SAI) is used to identify an area 
consisting of one or more cells belonging to the same Location Area. 
Such an area is called a Service Area and can be used for indicating 
the location of a UE to the CN. 

The Service Area Code (SAC) together with the PLMN-ld and the 
LAC constitute the Service Area Identifier. 

SAI = PLMN-ld II LAC II SAC 
The SAC is defined by the operator, and set in the RNC via O&IVI. 


Access network type 
specific (ID specific to 
3GPP networks) 


SNA-Id 


12.6 


The Shared Network Area Identifier (SNA-Id) is used to identify an 
area consisting of one or more Location Areas. Such an area is 
called a Shared Network Area and can be used to grant access 
rights to parts of a Shared Network to a UE in connected mode (see 
3GPPTS 25.401 ). 

The Shared Network Area Identifier consists of the PLMN-ld 
followed by the Shared Network Area Code (SNAC). 

SNA-Id = PLMN-ld II SNAC 
The SNAC is defined by the operator. 


Access network type 
specific (ID specific to 
3GPP networks) 




13 


Numbering, addressing and identification within the IP 
multimedia core network subsystem 




Private User 
ID 


13.3 


The private user identity shall take the form of an NAI, and shall 
have the form username@realm as specified in clause 2.1 of 
RFC 4282 




Public User ID 


13.4 


The Public User Identity shall take the form of either a SIP URI (see 
RFC 3261 or a tel URL (see RFC 3966 ). A SIP URI for a Public 
User Identity shall take the form "sip:user@domain". SIP URI 
comparisions shall be performed as defined in RFC 3261 , section 
19.1.4. 




PSI 


13.5 


The Public Service Identity (PSI) shall take the form of either a SIP 
URI (see RFC 3261 ) or a tel URL (see RFC 3966 ). 
A public service identity defines a service, or a specific resource 
created for a service. 






14 


Numbering, addressing and identification needed to access the 
3GPP system supporting the WLAN interworking 




Home network 
realm 


14.2 


The home network realm shall be in the form of an Domain Name as 
specified in RFC1035 




Root NAI 


14.3 


The Root NAI shall take the form of a NAI, and shall have the form 
'username@realm' as specified in clause 2,1 of RFC 4282. 




Decorated NAI 


14.4 


The Decorated NAI shall take the form of a NAI, and shall have the 
form 'homerealmlusername@otherrealm as specified in clause 2.73 
of RFC 4282. 




Temporary Ids 


14.5 


The Temporary Identities (Pseudonyms and re-authentication 
identities) shall take the form of a Network Access Identifier (NAI) 
username as specified in clause 2,1 of the RFC 4282 




Alternative 
NAI 


14.6 


The Alternative NAI shall take the form of a NAI, i.e. 
'any_username@REALM' as specified in RFC 4282. 
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Identifier 
name 


Clause in 
[6] 


Definition in TS 123 003 [6] 


TISPAN statements 


W-APN 
Networl< 
Identifier 


14.7.1 


A W-APN Network Identifier may be used to access a service 
associated with a PDG. This may be achieved by defining: 

a W-APN Network Identifier consisting of 3 or more labels 
and starting with a Reserved Service Label, or a W-APN 
Network Identifier consisting of a Reserved Service Label 
alone, which indicates a PDG by the nature of the requested 
service. Reserved Service Labels and the corresponding 
services they stand for shall be agreed between operators 
who have WLAN roaming agreements. 


Access network type 
specific (ID specific to 
3GPP networks) 


W-APN 
Operator 
Identifier 


14.7.2 


The W-APN Operator Identifier is composed of four labels. The last 
label shall be "pub.3gppnetwork.org". The second and third labels 
together shall uniquely identify the PLIVIN. The first label 
distinguishes the Domain Name as a W-APN. 
For each operator, there is a default W-APN Operator Identifier (i.e. 
Domain Name). This default W-APN Operator Identifier is derived 
from the IMSI as follows: 

"w-apn.mnc<MNG>.mcc<MCG>. pub. 3gppnetwork.org" 


Access network type 
specific (ID specific to 
3GPP networks) 




15 


Identification of Multimedia Broadcast/Multicast Service 




TMGI 


15.2 


Temporary Mobile Group Identity (TMGI) is used within MBMS to 
uniquely identify Multicast and Broadcast bearer services.. 
The TMGI is composed of three parts: 

1 ) MBMS Service ID consisting of three octets. MBMS Service 
ID uniquely identifies an MBMS bearer service within a 
PLMN. 

2) Mobile Country Code (MCC) consisting of three digits. The 
MCC identifies uniquely the country of domicile of the BM- 
SC; 

3) Mobile Network Code (MNC) consisting of two or three 
digits. The MNC identifies the PLMN which the BM-SC 
belongs to. The length of the MNC (two or three digits) 
depends on the value of the MCC. 


Access network type 
specific (ID specific to 
3GPP networks) 




16 


Numbering, addressing and identification within the GAA 
subsystem 




BSF address 


16.2 


The Bootstrapping Server Function (BSF) address is in the form of a 
Fully Qualified Domain Name as defined in RFC 1035. The UE shall 
discover the BSF address from the identity information related to the 
UICC application that is used during the bootstrapping procedure i.e. 
IMSIforUSIM, orlMPIforlSIM. 


Not defined in TISPAN 

Release 1 

ffs in later releases 




17 


Numbering, addressing and identification within the Generic 
Access Network 




Home network 
realm 


17.2.1 


The home network realm shall be in the form of an Internet domain 
name, e.g. operator.com, as specified in RFC 1035. 




Full 

Authentication 

NAI 


17.2.2 


The Full Authentication NAI in both EAP-SIM and EAP-AKA shall 
take the form of an NAI as specified in clause 2.1 of RFC 4282. 


Not defined in TISPAN 

Release 1 

ffs in later releases 


Fast Re- 
Authentication 
NAI 


17.2.3 


The Fast Re-authentication NAI in both EAP-SIM and EAP-AKA 
shall take the form of an NAI as specified in clause 2.1 of RFC 4282. 


Not defined in TISPAN 

Release 1 

ffs in later releases 


Home network 
Domain Name 


17.3.1 


The home network Domain Dame shall be in the form of a Domain 
Name, e.g. operator.com, as specified in RFC 1035. 




Provisioning 

GANC-SEGW 

ID 


17.3.2 


The Provisioning GANC-SEGW identifier shall take the form of a 
Fully Qualified Domain Name as specified in RFC 1035. 


Access network type 
specific (ID specific to 
3GPP networks) 


Provisioning 
GANG ID 


17.3.3 


The Provisioning GANG identifier shall take the form of a fully 
qualified domain name (FODN) as specified in RFC 1035. 


Access network type 
specific (ID specific to 
3GPP networks) 
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A.2 Additional Identifiers necessary for TISPAN NGN 
A.2.1 Organization of User Data 

This table is taken from TR 182 005 (see bibliography) for TISPAN Release 1. 



Parameter 


Clause 


CLF 


PDBF 


Assigned IP Address 


9.1.1.1 


T 




Address Realm 


9.1.1.2 


T 




Subscriber Id 


9.1.2 


T 


P 


Default Subscriber ID 


9.1.3 


P 




Physical Access ID 


9.2.1 


T 




Logical Access ID 


9.2.2 


T 




Access Network Type 


9.2.3 


P 




Terminal Type 


9.2.4 


T 




Privacy Indicator 


9.3.1 


T 


P 


Location Information 


9.3.2 


P 




Geographic Location Information 


9.3.3 


T 




QoS Profile Information 


9.4.1 


T 


P 


Initial Gate Settings 


9.4.2 


T 




RAGS Point of Contact 


9.5.1 


P 




GNCGF address 


9.5.2 




P 


P-CSCF Identity 


9.5.3 




P 


AF Identity 


9.5.4 


T 





A.2.2 Network Attachment Subsystem (MASS) 

Additional IDs in the NASS document ES 282 004 [14] for TISPAN Release 1. 
No new additional IDs are contained in the NASS document. 

A.2. 3 Resource and Admission Control Subsystem (RACS) 

Additional ID's in the RACS document ES 282 003 [15] for TISPAN Release 1. 



Parameter 


Clause 


Charging Correlation identifier 


5.2.2 


RACF identification 


5.2.3.1.2 


Application function identifier 


5.2.3.1.5 


Resource Bundle Identifier 


5.2.3.1.6 


IVIedia Session Identifier 


5.2.3.3.2 


Flow Identifier 


5.3.1.3.1 



A. 3 Summarization of Access IDs 

Following are some access IDs derived from NASS document ES 282 004 [14] for TISPAN Release 1. 

IP Address: The IP address of the attached user equipment. 

Address Realm: The addressing domain in which the IP address is significant. 

Physical Access ID: The identity of the physical access to which the user equipment is connected. 

Logical Access ID: The identity of the logical access used by the attached user equipment. In the xDSL case, 
the Logical Access ID may explicitly contain the identity of the port, VP and/or VC carrying the traffic. 

Subscriber ID: The identity of the attached user. 
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Static Information derived from the Physical access ID: 

Location Information. 

Default Subscriber ID. 
Static Information Derived from the Logical Access ID: 

RACS point of contact: The address of the RACS element where the subscriber profile should be pushed. 

Access Network Type: The type of access network over which IP connectivity is provided to the user 
equipment. 
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